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ABSTRACT 


Increasing  demand  for  software  and  increasing  shortfalls 
of  programmers  have  focused  efforts  to  improve  software 
project  productivity  on  the  role  of  the  software  project 
manager.  The  complex  dynamics  of  software  project 
development,  and  the  "visibility"  of  the  project,  affect 
decision  making  and  performance  to  a  large  degree.  Using  the 
System  Dynamics  Model  for  software  project  management,  these 
and  other  issues  can  be  evaluated  with  low  financial  risk  or 
outlays  through  simulation  of  software  projects. 

This  thesis  investigates  the  effect  of  changing  one  of  the 
dynamics  (i.e.,  size)  on  the  behavior  and  performance  of  the 
project  manager  by  using  a  simulation  of  an  actual  software 
project  in  a  game  environment.  Analysis  of  the  results 
indicates  that  increased  visibility  significantly  improves 
project  schedule. 
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I .  INTRODUCTION 


A.  BACKGROUND 

Software  project  management  is  not  only  facing  a  serious 
backlog  of  projects  that  need  to  be  maintained,  created  and 
designed,  but  also  an  increasing  shortfall  of  trained 
programmers  available  to  do  the  job.  Recognizing  the 
increased  workload  and  the  decreasing  workforce,  technological 
advances  have  assisted  productivity,  but  show  no  signs  of 
catching  up  with,  let  alone  meeting  demand. 

As  usual,  management  of  the  process  has  come  under 
increasing  scrutiny  as  the  last  hope  of  the  software  project 
manager.  Software  project  management  is  far  more  complex, 
however,  than  the  management  of  a  hardware  or  industrial 
project.  The  dynamics  of  resource  management  are  far  more 
coitplex,  due  to  the  continual  shifts  in  work  force, 
technological  situation,  supply  and  demand  of  supporting 
resources,  requirements  and/or  specifications,  etc. 

Two  crucial  elements  of  any  project  manager's  resource 
allocation  plan  are  people  and  time/cost.  Faced  with  the 
realities  of  a  competitive  job  market,  tight  schedules  and  a 
budget,  the  manager  must  consider  not  only  those  factors,  but 
their  possible  effects  on  all  other  factors.  Of  significant 
interest,  given  the  statistics  on  personnel  availedjility  and 
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project  size  growth,  are  projections  of  what  is  best  for  a 
manager  to  do  in  the  face  of  schedule  expectations  and  growth 
realities. 

DeMarco  asserts  that  the  "political"  pressures  affecting 
schedule  and  cost  status  reporting  are  more  appropriately 
called  sociological  factors,  because  of  the  complex  social 
dynamics  involved  [Ref.  1]  .  Because  of  this,  the  status 
reported  and  its  interpretation  often  negatively  affect  the 
progress  of  the  project.  The  concept  of  project  "visibility," 
an  accurate  representation  not  only  of  the  project's  size  but 
also  of  actual  progress  made,  is  cited  in  the  literature 
(DeMarco,  Abdel -Hcimid)  as  being  key  to  controlling  and 
reducing  project  schedule  and  cost  overruns  [Ref.  2]  [Ref.  3]  . 

The  "90%  Syndrome"  is  a  tendency  in  which  Baber  suggests 

Estimates  of  the  fraction  of  work  completed  [increase]  as 
originally  planned  until  a  level  of  80-90%  is  reached. 
The  programmer's  individual  estimates  then  increase  only 
very  slowly  until  the  task  is  actually  completed  [Ref.  4]  . 

According  to  Abdel-Hamid  [Ref.  2],  there  is  "ample  evidence  in 

the  literature  to  indicate  that  this  phenomenon  is  pervasive 

in  software  project  management,"  and  that  it  affects  many  of 

the  other  factors  involved.  How  the  project  manager  copes 

with  this  problem  while  managing  resources  to  deal  with 

changes  in  project  size  or  complexity  is  of  crucial  in^ortance 

to  the  success  (being  on  time,  within  budget  and  meeting  the 

user  requirements)  of  a  project. 
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B.  PURPOSE  OF  RESEARCH 

The  purpose  of  this  thesis  is  to  design,  construct  and 
execute  an  experiment  involving  the  single  project  management 
environment,  using  the  Systems  Dynamic  Model  (SDM)  gaming 
interface.  The  Systems  Dynamic  Model  is  a  comprehensive  model 
of  the  dynamics  of  software  development,  allowing  simulation, 
testing  and  evaluation  of  different  software  project 
management  environments.  It  allows  one  or  several  factors  to 
be  manipulated  while  holding  all  others  constant,  and  offers 
a  cost  effective  opportunity  to  study  the  dynamics  of  decision 
making  in  a  dynamic  environment. 

This  experiment  addresses  the  effect  of  project  size 
change  on  project  processes  and  performance.  The  concept  of 
visibility  has  been  discussed  in  terms  of  management 
situations,  but  has  not  been  empirically  tested  in  any  project 
management  domain  in  the  literature  dealing  with  change  or 
project  management. 

The  gaming  interface  presents  the  subject  managers  with  a 
standard  interface  to  the  model;  they  are  required  to  make 
staffing  level  decisions  and  project  cost  estimates  through 
the  design  and  testing  phases  of  a  software  develoment 
project.  Their  performance  is  measured  by  their  final  cost 
and  completion  date  of  the  project.  The  SAS  statistical 
software  is  then  used  to  measure  process  and  performance 
deviation  significance;  the  effect  of  the  manipulated 
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variables  on  the  actions  and  performance  of  the  subject 
managers . 

C.  SCOPE  OF  RESEARCH 

The  scope  of  this  research  includes  the  design, 
construction,  preparation  of  software  and  documentation,  and 
execution  of  the  single  project  experiment  to  investigate  the 
following  hypotheses  (stated  in  alternative  form) : 

1 .  Process  Hypotheses 

la.  Project  managers  presented  with  gradual  change  in 
project  size  will  make  different  cost  estimate  decisions  than 
project  managers  presented  with  an  abrupt  increase  in  size  of 
the  same  magnitude. 

lb.  Project  managers  presented  with  gradual  change  in 
project  size  will  make  different  staffing  decisions  than 
project  managers  presented  with  an  abrupt  increase  in  size  of 
the  same  magnitude. 

2 .  Performance  Hypothesis 

Project  managers  presented  with  gradual  change  in 
project  size  will  perform  differently  than  project  managers 
presented  with  an  abrupt  increase  in  size  of  the  same 
magnitude. 

D.  ASSUMPTIONS 

The  students  in  this  experiment  were  fifth-quarter  (in  a 
six-quarter  curriculum)  graduate  students  enrolled  in  the 
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Computer  Systems  Managemenc  curriculum  at  the  Naval 
Postgraduate  School.  Although  the  students  were  not  actual 
software  project  managers,  the  amount  of  education  in  software 
project  management  and  related  svibjects  provided  thus  far  in 
the  curriculum,  coupled  with  general  management  experience  in 
their  careers  to  date  lends  credence  to  the  assumption  that 
the  results  of  the  experiment  and  the  findings  and  conclusions 
would  be  representative  of  the  industry.  This  assumption  is 
further  supported  by  the  findings  of  William  Remus  [Ref.  5] . 

E.  THESIS  ORGANIZATION 

Chapter  II  is  a  description  of  the  experiment  design,  to 
include  software  and  documentation  and  preparation  of  the 
experiment  itself  and  the  description  of  a  trial  experiment, 
its  lessons  and  the  changes  made  to  the  experiment  as  a 
result.  Chapter  III  describes  in  depth  the  methodology, 
sample  population  and  conduct  of  the  experiment .  Chapter  IV 
provides  a  validation  and  analysis  of  the  experimental  raw 
data.  Chapter  V  summarizes  the  findings  of  the  previous 
chapters  and  their  implications,  and  provides  recommendations 
for  further  research. 
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II.  PREPARING  THE  GAMING  INTERFACE 


A.  EXPERIMENTAL  DESIGN 

This  experiment  uses  the  Systems  Dynamic  Model  to  develop 
an  experimental  simulation  of  a  software  project;  this  allows 
the  creation  of  a  "game"  not  unlike  a  flight  simulator,  in 
that  the  player  must  pilot  the  project  from  point  A  to  point 
B  within  given  constraints  and  guidelines.  The  simulation 
mimics  a  software  project  from  the  start  of  its  Design  Phase 
until  the  end  of  the  Testing  Phase. 

The  player,  or  subject,  plays  the  role  of  manager  of  a 
software  project;  when  he/she  initiates  the  'game"  program, 
the  program  presents  an  introductory  screen  (Figure  2-1)  that 
reiterates  the  decisions  (staffing  levels  and  project  cost 
estimates)  that  t;.e  player  is  expected  to  make  as  manager 
based  on  periodic  status  reports.  It  then  prompts  the  user  to 
initiate  the  first  simulated  time  interval  of  40  days  (two 
months)  and  performs  the  simulation. 

Once  the  simulation  of  an  interval  is  completed,  the  game 
program  displays  a  revised  status  report  of  the  project  based 
on  the  40 -day  interval,  to  include  an  updated  size  estimate 
and  an  estimate  of  the  percentage  of  development  and/or 
testing  which  has  been  completed  (Figure  2-2) .  Based  on  this 
information,  the  user  may  input  a  new  desired  staffing  level. 
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Important  Points  to  Remember  1  !!!!!!! ! 

** ********  ***************  ************* 

-  You  are  not  allowed  to  discuss  this  exercise  with 
anyone  other  than  a  lab  attendant.  Please  refrain  from 
discussing  this  with  other  class  members  until  they 
have  con^Jleted  the  project. 

-  The  system  will  run  through  the  first  simulation 
period  (2  months)  and  provide  you  with  a  status  report. 
At  the  end  of  each  reporting  period,  you  will  have  an 
opportunity  to  revise  the  estimated  total  project  cost 
(in  man  days) ,  and  to  revise  your  desired  staff  level. 

-MaJce  your  changes  to  the  cost  estimate  and  the 
desired  staffing  level  both  on  the  documentation  sheet 
provided  and  on  the  screen. 

A  LAB  ATTENDANT  MUST  VERIFY  YOUR  FINAL  RESULTS! 

-  GOOD  LUCK!  Press  <ENTER>  to  continue. 


FIGURE  2-1  Introductory  Screen 


or  accept  the  previous  level  (which  is  the  default)  ,  and  input 
a  new  estimated  project  cost  (in  man  days)  or  accept  the 
previous  value  (default) . 

Once  these  values  are  input  or  accepted,  and  entered  on  a 
data  documentation  sheet  provided  to  each  player,  the  game 
prompts  the  player  to  continue  to  the  simulation  of  the  next 
interval.  The  game  continues  until  the  project  is  complete  in 
terms  of  development  and  testing,  and  indicates  the  time 
(schedule)  and  cost  (man  days)  of  completion.  Players  are 
under  no  staffing  level  or  project  cost  estimate  constraints, 
although  they  are  reminded  before  the  game  begins  of  the  need 
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PROJECT  STATUS  REPORT 


ELAPSED  TIME  =====*==*>  40  Days 

ESTIMATES  MADE  AT  THE  START  OF  THE  PROJECT 
Project  Size  396  Tasks 

Project  Cost  in  Man  Days  l,lll  Man  Days 

Project  Duration  320  Days 

PROJECT  STATUS  at  Time  ======*«>  40  Days 

Updated  Estimate  of  Total  Project  Size  396.50  Tasks 
Development (Design  &  Code) 

Reported  Complete  12.84  Percent 

%  Testing  Reported  Con^lete  0.00  Percent 

Updated  Estimate  of  Total  Man  Days  1,111  Man  Days 
Total  Man  Days  Expended  to  date  164.17  Man  Days 
Updated  Est.  of  Project  Duration 
(start -end)  229  Days 

Current  Staff  Size  4.5  Fulltime  Staff 


PRESS  <ENTER>  TO  RETURN  TO  MENU 


FIGURE  2-2  PROJECT  STATUS  REPORT 

to  remain  as  close  as  possible  to  the  budgeted  schedule  and 
cost . 

The  actual  experiment  consisted  of  two  different  SDM 
models,  both  of  which  were  based  on  a  NASA  experiment  which 
has  been  used  as  a  basis  for  other  research  efforts.  By  using 
real  data  from  real  projects,  we  can  measure  and  compare  the 
results  of  the  experiment  to  a  known  baseline  based  on 
reality.  Subjects  were  divided  randomly  into  two  groups. 
Group  GRADUAL  was  directed  to  run  the  'EXPl'  program,  in  which 
they  were  presented  with  a  simulated  software  project  that 
grew  gradually  in  size  from  320  tasks  (a  task  being  equal  to 
approximately  50  lines  of  code)  to  610  tasks  by  day  100. 


Group  ABRUPT  players  ran  the  'EXP2'  program,  in  which  they 
managed  a  project  which  remained  the  same  size  (320  tasks) 
through  the  100th  day  of  the  simulation;  after  the  Day  80 
status  report,  the  players  received  a  message  on  the  screen 
alerting  them  that  due  to  increased  requirements,  the  project 
size  had  just  increased  to  610  tasks.  After  this  point,  the 
estimated  size  of  the  project  remained  the  same  (at  610 
tasks) . 

The  motivation  in  each  case  was  the  same;  the  subjects 
were  told  that  their  participation  in  the  experiment  would  be 
rewarded  with  extra  credit  points  in  the  Software  Engineering 
course  they  were  taking.  Although  the  number  of  points  they 
would  receive  was  not  linked  to  their  performance,  they  were 
told  that  their  objective  was  to  complete  the  project  as  close 
as  possible  to  the  original  estimates  of  schedule  and  cost. 
These  original  estimates  appeared  at  the  top  of  the  status 
report  for  each  time  interval. 

Two  days  prior  to  the  conduct  of  the  actual  experiment, 
each  subject  received  an  initial  45-minute  briefing  regarding 
their  objectives  in  the  experiment,  possible  ways  of 
interpreting  the  status  reports,  and  advice  regarding  the 
reliedsility  of  estimates  in  software  projects.  Prior  to  the 
actual  experiment,  each  subject  performed  a  trial  run 
simulation  called  TEST  on  an  individual  basis;  the  design  and 
documentation  is  discussed  later  in  this  chapter.  The  purpose 
of  these  training  and  orientation  sessions  was  to  eliminate 
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discomfort  or  unfaumiliarity  with  the  interface  and  the  game. 
The  TEST  simulation  revealed  no  increase  in  size  of  the 
project,  nor  did  it  allow  the  simulation  to  run  beyond  the  80- 
day  interval,  in  order  to  preclude  advance  knowledge  or  bias 
of  the  actual  experiment.  Each  subject  thus  played  the  TEST 
simulation  for  two  40 -day  periods,  then  exited  the  TEST 
program  and  initiated  the  EXPl  or  EXP2  program,  depending  on 
their  group. 

B .  THE  SOFTWARE 

In  order  to  construct  the  experiment,  the  gaming  interface 
of  the  SDM  model  had  to  be  tailored  to  the  experimental 
design,  and  explanatory  documentation  developed  to  outline  the 
background,  instructions,  tasks,  rules  and  other 
considerations  to  the  subjects. 

The  interface  includes  the  Dynamo  simulation  files  and 
Dynex  files,  which  allow  the  model  designer  to  interface  with 
the  simulation  language  and  construct  the  experimental  design. 
Once  complete,  the  interface  is  transparent  to  the 
experimental  subject,  who  simply  starts  and  plays  the  'game' 
without  knowledge  of  the  workings  of  the  simulation  itself. 
Further,  the  interface  must  include  the  means  for  capturing 
the  raw  data  obtained  from  each  subject's  decisions  for 
further  analysis. 

The  language  interface  that  the  designer  of  the  experiment 
uses  is  called  Dynex.  Through  the  use  of  any  text  editor,  the 
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Dynex  (or  DNX)  file  is  created  to  perform  the  following 
functions;  display  information  to  the  player  identifying  what 
the  player  needs  to  do,  capture  the  variables  input  by  the 
player  required  for  the  simulation,  and  provide  a  format  for 
the  output  (status  report)  screens.  Copies  of  the  TEST,  EXPl 
and  EXP2  Dynex  files  and  their  associated  screens  are  in 
Appendices  A,  B,  and  C,  respectively. 

The  interface  is  controlled  by  a  batch  (BAT)  file  of  the 
Scune  name,  which  invokes  the  interface,  provides  instructions 
after  each  simulation  is  completed,  invokes  the  display  of  the 
status  report  or  the  initiation  of  the  next  set  of  player 
inputs  and  provides  overall  'play-by-play'  control  of  the 
game's  events.  Copies  of  the  TEST,  EXPl,  and  EXP2  batch 
control  files  are  in  Appendices  D,  E,  and  F,  respectively. 

C.  THE  DOCUMENTATION 

Each  subject  received  a  set  of  instructions  which 
describes  the  background,  scope  and  procedures  for  the  gaming 
interface.  This  documentation  gives  the  siibject  a  clear 
understanding  of  his/her  role  in  the  experiment,  explains  the 
status  report  screens  (an  example  is  shown  in  Figure  2-2) ,  and 
presents  procedures  for  running  the  TEST  simulation  as  well  as 
unique  instructions  for  the  specific  experimental  version. 
The  background  and  instructions  were  the  same  for  both  groups; 
the  only  difference  in  the  documentation  was  the  batch 
filename  (EXPl  or  EXP2)  in  the  EXPERIMENT  portion  of  the 
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instructions  that  the  subject  is  directed  to  enter  once  the 
TEST  simulation  is  completed. 

This  docximentation  was  provided  to  each  subject  prior  to 
moving  to  the  computer  ledioratory  for  the  TEST  simulation  and 
actual  experiment.  It  was  thoroughly  discussed,  and  all 
questions  about  its  contents  were  answered  before  any  subjects 
began  the  experiment.  The  sxibjects  were  directed  verbally  and 
in  the  instructions  to  run  the  TEST  simulation  first,  and  were 
told  not  to  write  any  estimates  or  staffing  decisions  down 
while  running  TEST.  As  previously  stated,  the  TEST  simulation 
mirrored  the  actual  experiments,  without  revealing  their 
content  or  nature.  The  TRIAL  RUN  and  EXPERIMENT  instructions 
portion  of  the  documentation  gave  each  subject  step-by-step 
directions  and  the  unique  batch  filename  for  initiating  their 
particular  experiment  (EXPl  or  EXP2)  once  they  stopped  the 
TEST  simulation  after  two  time  periods  (80  days) .  A  copy  of 
the  documentation  and  instruction  set  is  in  Appendix  G. 

The  final  page  of  the  docximentation,  the  staffing  level 
and  project  cost  estimate  record  sheet,  provides  the 
researcher  a  means  of  capturing  the  staffing  level  and  cost 
estimate  decisions  made  by  each  svibject.  This  page  identifies 
the  initial  estimates  of  the  size  (396  tasks,  where  a  task  is 
approximately  50  lines  of  code),  cost  (l,lll  man  days)  and 
duration  (320  days)  of  the  project,  as  well  as  the  size  of  the 
initial  core  team  (5  people)  .  It  also  specifies  when  a 
project  is  considered  'complete'  (when  "%  Reported  Coir^lete* 
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equals  100  for  both  Development  (Design  and  Coding)  and 
Testing)  ,  and  provides  blank  spaces  for  project  cost  estimates 
and  staffing  level  decisions  to  be  recorded  by  the  subject  for 
each  time  period.  A  copy  of  this  record  sheet  is  in 
Appendix  H. 

D.  THE  TRIAL  EXPERIMENT 

Once  the  gaming  interface  and  documentation  were  prepared, 
trial  experiments  were  conducted  to  provide  feedback  on 
potential  design  or  procedural  problems.  Four  students  who 
had  knowledge  of  personal  computers  were  selected  to  play  the 
'game'  as  trial  experiments.  The  objective  of  the  trial 
experiment  was  to  measure  the  individuals'  interaction  with 
the  gaming  interface  and  the  documentation.  Additionally, 
these  students  would  become  laboratory  assistants  for  the 
conduct  of  the  actual  experiment,  so  their  participation  in 
the  trial  experiment  served  to  give  them  hands-on  experience 
with  the  experiment  and  the  interface  itself.  Specific 
concerns  to  be  excunined  in  the  trial  experiment  were: 

•  Are  the  instructions  clear? 

•  Are  the  subjects  comfortable  with  the  gaming  interface? 

•  How  long  does  the  experiment  take? 

•  What  are  the  questions  the  researcher  and  lab  assistants 
need  to  be  prepared  to  answer? 

•  Two  of  the  subjects  of  the  trial  experiment  used  the  EXPl 
gaming  interface  (gradual  increase  in  size) ,  while  the 
other  two  subjects  used  the  EXP2  interface  (sudden  change 
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in  requirements)  .  Two  subjects  were  not  provided  a  trial 
run  while  the  other  two  subjects  used  the  TEST  simulation 
before  going  on  to  the  actual  experimental  versions. 
Pertinent  observations  and  lessons  learned  were: 

•  Average  time  for  the  experiment  was  45  minutes,  including 

instruction  review,  simulation,  and  saving  information  to 
disk.  Inclusion  of  the  TEST  simulation  added 

approximately  10  minutes  to  the  experiment's  duration. 

•  The  first  two  subjects,  who  did  not  have  the  TEST  trial 
run,  expressed  a  need  for  one,  saying  that  they  had 
thought  that  the  first  two  time  periods  were  a  trial  run. 
They  also  said  that  the  trial  run's  start  and  finish 
should  be  clearly  delineated  in  the  written  and  on-screen 
directions,  to  preclude  confusion.  The  two  subjects  who 
ran  the  TEST  simulation  felt  more  comfortable  with  the 
actual  experiment  than  the  two  who  had  not ,  and  had  no 
problems  transitioning  from  the  TEST  simulation  to  the 
actual  experimental  version. 

•  One  subject  expressed  a  need  for  scrap  paper  on  which  to 
perform  calculations.  Although  the  scrap  paper  was 
provided,  all  subjects  in  the  actual  experiment  were  told 
to  rely  on  their  judgement  as  opposed  to  standard  metrics, 
such  as  COCOMO. 

•  Heuristics  and  metrics  techniques  presented  in  the  ongoing 
Software  Development  class  from  which  all  of  the  subjects 
came  were  a  stumbling  block  for  two  of  the  four  subjects. 
The  information  presented  in  the  initial  estimates  and  the 
status  reports  conflicted  with  what  the  course  had  taught 
them  to  expect.  They  recommended  that  reliance  on 
judgement,  rather  than  metrics,  be  stressed  in  the  initial 
briefing  and  during  the  conduct  of  the  experiment. 

•  One  of  the  subjects,  who  ran  the  EXP2  simulation  (sudden 
increase  in  size) ,  did  not  react  at  first  to  the  change, 
as  he  thought  it  was  caused  by  something  he  had  done.  To 
remedy  this,  the  warning  screen  alerting  the  subject  to 
the  change  in  requirements  was  made  larger,  and  preceded 
by  a  notice  to  pay  attention  to  the  next  screen. 

•  Computers  equipped  with  a  math  coprocessor  and/or  80386 
microprocessors  performed  the  simulations  and  provided 
faster  response  to  subjects  than  those  machines  not  so 
equipped.  To  reduce  the  response  time  as  much  as 
possible,  only  computers  with  hard  drives  would  be  used, 
and,  to  the  extent  possible,  only  those  equipped  with  math 
coprocessors  and/or  80386  microprocessors. 
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E.  FINAL  PREPARATIONS 

The  changes  noted  in  the  lessons  learned  were  implemented 
in  the  gaming  interface  and  documentation,  and  the  initial 
briefing  included  the  emphasis  on  individual  judgement  rather 
than  metrics.  Group  GRADUAL  was  defined  as  the  group  of 
subjects  that  would  'play'  the  EXPl  (gradual  size  increase) 
simulation,  while  Group  ABRUPT  would  be  the  group  of  subjects 
using  the  EXP2  (sudden  size  increase)  simulation.  As 
indicated  before,  the  difference  in  the  simulations  occurred 
within  the  Dynex  control  file,  and  was  transparent  to  the 
subject. 

The  final  copies  of  the  documentation  for  the  two  groups 
differed  only  in  the  batch  filename  that  was  provided  to  start 
the  actual  experiment;  all  other  guidelines,  information  and 
record  sheets  were  identical.  A  folder  was  prepared  for  each 
subject;  it  included  a  copy  of  the  documentation,  scrap  paper, 
a  survey  addressing  the  subject's  academic  and  worJc 
experience,  and  a  diskette  that  contained  the  TEST  and 
appropriate  experimental  version  (EXPl  or  EXP2)  simulation 
programs.  Additional  preparations  included  assuring  the 
availability  of  the  computer  laboratories,  ascertaining 
individual  computer  status,  loading  of  required  files  on  the 
hard  drives  of  the  conputers  and  preparing  schedules  and 
seating  charts. 
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III.  CONDUCTING  THE  EXPERIMENT 


A.  TASKS  AND  PROJECT  CHARACTERISTICS 

The  research  sxibjects,  having  received  the  initial 
briefing  two  days  prior  to  the  actual  experiment,  were 
familiar  with  the  skills  expected  of  a  software  project 
manager.  Experiencing  the  TEST  simulation  trial  run 
immediately  prior  to  the  actual  experiment  ensured  that  they 
were  familiar  with  the  gaming  interface  itself. 

The  two  experiment  simulation  scenarios,  EXPl  and  EXP2, 
were  designed  to  allow  the  experimental  subjects  to  make  two 
decisions  for  each  40 -day  time  period,  based  on  the  initial 
information  and  status  reports  they  received  from  the 
simulations,  until  the  completion  of  the  project.  The  first 
decision  they  were  prompted  to  make  was  to  update  the 
project's  total  cost  estimate  (in  man  days).  The  second 
decision  was  to  determine  a  desired  staffing  level  for  the 
rest  of  the  project.  The  project  manager's  role  was  stressed 
as  that  of  resource  manager;  allocating  resources  as  necessary 
to  complete  the  project  on  time  and  within  the  projected 
budget,  as  close  as  possible  to  the  original  estimates. 

Subjects  used  the  gaming  interface  to  enter  their 
decisions  for  each  time  period,  and  were  provided  with  a 
status  report.  This  report  was  designed  in  a  text  format. 
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which  also  allowed  the  data  in  each  status  report,  as  well  as 
the  final  cost  and  schedule  data  for  each  subject,  to  be 
captured  by  the  interface.  In  this  fashion,  staffing  and  cost 
estimate  decisions  were  captured  by  the  interface  as  well  as 
on  the  subject -completed  record  sheet. 

B.  ORGANIZING  THE  EXPERIMENT 

The  experimental  setting  consisted  of  a  15 -minute 
classroom  training  session  in  which  the  documentation,  seating 
assignments  and  guidelines  were  presented  and  questions 
resolved.  Due  to  the  size  of  the  groups  and  the  limited 
number  of  acceptable  computers  within  each  laboratory,  two 
different  IcdDoratories  were  used,  with  one  laboratory 
assistant  in  each.  The  assistants  answered  general  questions 
about  the  procedure  or  gaming  interface,  but  did  not  answer 
questions  about  the  actual  decisions  to  be  made.  When  asked 
about  relative  importance  of  schedule  or  cost,  the  assistants 
merely  reiterated  the  guidance  contained  in  the  documentation; 
as  close  as  possible  to  the  original  estimates  of  schedule  and 
budget.  The  subjects  received  their  individual  folders  at  the 
beginning  of  the  training  session,  and  were  directed  to  their 
respective  seating  locations  once  in  the  laboratories.  In 
order  to  avoid  inadvertent  sharing  of  status  report  or  other 
information,  the  seating  ensured  alternation  of  Group  GRADUAL 
and  Group  ABRUPT  players  in  the  ledsoratory.  Additionally, 
subjects  were  instructed  to  perform  their  o%m  work  and 
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informed  that  since  several  versions  of  the  simulation  were 
being  used,  anyone  else's  data  or  decisions  could  be 
misleading.  Each  laboratory  assistant  had  a  full  set  of 
backup  diskettes  and  instructions  so  that  any  problem  could  be 
immediately  resolved,  and  backup  computers  were  designated  on 
the  seating  chart  in  the  event  of  a  system  malfunction. 

C.  THE  SAMPLE  POPULATION 

The  subjects  for  this  experiment  were  students  from  a 
graduate  level  software  engineering  and  management  course, 
IS-4300,  at  the  Naval  Postgraduate  School  in  Monterey, 
California.  The  course  was  divided  into  two  sections; 
Segment  1  consisted  of  28  students,  and  Segment  2  consisted  of 
27  students.  After  the  names  of  the  researcher  and  the 
laboratory  assistants  were  removed  from  the  course  rosters, 
the  following  matched  sample  procedure  was  followed  to 
randomize  the  sample  population  and  assign  them  to 
experimental  groups  [Ref.  6]. 

A  two- level  randomization  was  perfomed  using  an 
alphcLbetical  list  of  students  in  each  segment  and  a  standard 
todile  of  random  digits  [Ref.  7] .  The  population  randomizing 
worksheet  used  for  each  section  is  at  Appendix  I.  Column  A  is 
the  alphcdsetical  list  of  the  students  in  each  section;  Colvimn 
B  is  a  two-digit  random  number  taken  from  the  standard  tsdjle 
of  random  numbers  and  assigned  to  each  student.  The  random 
numbers  for  Segment  1  were  assigned  beginning  with  row  20  of 


the  table;  random  numbers  for  Segment  2  were  assigned 
beginning  with  row  14.  The  list  of  students  for  each  segment 
was  then  sorted  into  ascending  order  of  random  number.  This 
randomized  the  alphabetical  list  in  the  first  level  (Column 
C)  .  These  first  level  randomized  lists  were  then  assigned 
random  numbers  from  the  table;  Segment  l  with  numbers 
beginning  with  row  9,  and  Segment  2  with  nxambers  beginning 
with  row  37  of  the  table  (Column  D)  .  This  list  was  again 
sorted  into  ascending  order  of  random  number,  randor^izing  the 
original  alphabetical  list  to  the  second  level  (Column  E)  ; 
this  list  was  then  used  to  make  assignments  to  Groups  GRADUAL 
and  ABRUPT  by  alternating  the  group  assignments  (Column  F) . 

A  total  of  50  subjects  were  scheduled  to  participate  in 
the  experiment;  25  in  each  group.  One  subject  was  ill  and 
unable  to  participate,  so  was  dropped  from  the  sample 
population.  One  subject,  in  'playing'  the  game,  misunderstood 
the  instructions  and  repeatedly  pressed  the  numeric  key  "l" 
instead  of  entering  his  desired  staffing  level,  thereby 
nullif lying  his  decisions;  he  was  also  dropped  from  the  sample 
population.  These  students  are  designated  in  Appendix  I  by 
the  shading  of  their  names.  Both  had  been  assigned  to  the 
GRADUAL  Group,  SO  the  final  sample  populations  used  in  the 
experiment  consisted  of  23  subjects  in  Group  GRADUAL  and  25 
svibjects  in  Group  ABRUPT. 
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D.  DEPENDENT  MEASURES 

Under  certain  sequences  the  Dynamo  gaming  interface  does 
not  allow  some  projects  to  reach  design  and  testing  completion 
of  100  percent;  the  simulation  signifies  completion  by 
repeating  status  report  information  and  showing  an  elapsed 
time  that  is  not  a  multiple  of  the  40  day  period,  with  only 
about  97  percent  completion  of  design  and  testing.  The 
general  heuristic  used  to  verify  simulation  completion  was  the 
observance  of  the  97  percent  completion  report  and  the 
irregular  elapsed  time  figure. 

1.  Process  Variables 

The  first  process  dependent  variable  was  the  project 
cost  estimate  made  by  each  subject  at  the  end  of  each  time 
period.  The  line  on  the  Status  Report  Screen  from  Appendix  E 
which  reads  "Updated  Estimate  of  Trtal  Man  Days"  mirrors  the 
cost  estimate  made  by  the  subject  for  that  time  interval. 

The  second  process  dependent  variable  collected  as  a 
point  of  comparison  was  the  actual  staffing  level  decisions 
made  by  each  subject  at  the  end  of  each  time  interval.  This 
variable  was  not  reflected  in  the  Status  Report.  Each  subject 
decided  on  and  recorded  staffing  level  needs  on  the 
documentation  sheet  before  entering  them  into  the  computer. 
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2.  Perfoxmance  Variables 

The  subjects'  performance  was  operationalized  in  terms 
of  three  variables:  cost,  schedule  and  combined  cost  and 

schedule. 

The  first  dependent  variable  measured  as  an  output  of 
the  simulation  was  final  cost.  The  line  on  the  Status  Report 
Screen  in  Figure  2-2  which  reads  "Total  Man  Days  Expended  to 
Date"  is  the  cost  of  the  project  at  the  end  of  the  given 
reporting  period;  upon  completion  of  the  simulation,  this 
value  is  compared  with  the  original  project  cost,  and  the 
dependent  variable  DIFFCOST  is  calculated  as  a  percentage 
deviation  from  the  original  project  cost  [(COST  +  ORIGINAL 
COST)  /  ORIGINAL  COST]  represents  the  final  project  cost. 

The  second  dependent  variable  measured  as  an  output  of 
the  simulation  was  the  final  schedule.  The  line  on  the  Status 
Report  Screen  from  Appendix  E  which  reads  "Elapsed  Time" 
specifies  the  final  schedule  upon  completion  of  the 
simulation.  This  value  is  compared  with  the  original  project 
schedule,  and  the  dependent  variable  DIFFSKED  is  calculated  as 
a  percentage  deviation  from  the  original  project  schedule 
[ (SCHED  +  ORIGINAL  SCHED)  /  ORIGINAL  SCHED] . 

The  third  performance  dependent  variable  COSTSKED  was 
the  average  combined  difference  from  the  original  estimates  of 
cost  and  schedule  [DIFFCOST  +  DIFFSKED)  /  2] . 
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IV.  EXPERIMENTAL  RESULTS  AND  ANALYSIS 

A.  PREPARATORY  ANALYSIS 

1.  Model  of  Analysis 

The  raw  experimental  data  produced  a  final  cost  and 
schedule  for  each  project  manager,  as  well  as  their  staffing 
level  and  cost  estimate  decisions  for  each  time  interval. 
Analysis  of  the  data  is  based  on  the  comparison  of  decisions 
and  performance  between  the  two  groups,  GRADUAL  (gradual 
increase  in  project  size)  and  ABRUPT  (sudden  increase  in 
project  size) . 

The  SAS  General  Linear  Models  (GLM)  procedures  were 
used  for  Univariate  and  Multivariate  Analyses  of  Variance  and 
for  Repeated  Measures  analysis  due  to  the  inequal  populations 
involved  (22  subjects  in  the  GRADUAL  Group,  25  subjects  in  the 
ABRUPT  Group)  •  The  raw  data  is  presented  in  Appendix  J  as  the 
data  portion  of  the  SAS  control  files;  it  includes  the  name  of 
the  subject,  his/her  group  (GRADUAL  or  ABRUPT) ,  and  the 
individual's  final  schedule  and  final  cost. 

2.  Subjects 

a.  Student  Grade  Diatrxbution 

Students  were  randomly  assigned  to  either  of  two 
groups  as  described  in  a  previous  chapter.  There  were  no 
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significant  differences  between  the  two  groups  with  respect  to 
student  adjility,  as  reflected  in  their  end  of  course  grades 
(Sig  of  F  =  0.3497) . 

Jb.  Outliers 

Preliminary  SAS  data  analysis  was  performed  on  the 
raw  data,  and  revealed  one  sxibject  whose  final  cost  did  not 
fall  within  three  standard  deviations  of  the  mean  COST  (three 
standard  deviations  is  accepted  by  statistical  texts  as 
representing  99%  of  the  observations).  The  subject's  process 
and  performance  data  was  therefore  excluded  from  all  analyses, 
resulting  in  a  total  of  22  GRADUAL  Group  subjects  and 
25  ABRUPT  Group  subjects. 

B.  PROCESS  MEASURES  ANALYSIS  AND  RESULTS 

Following  the  approach  suggested  by  Winer  [Ref.  7], 
multivariate  analysis  of  variance  for  repeated  measures 
analyses  were  performed  on  staffing  level  and  cost  estimate 
decisions.  The  staffing  level  decision  data  for  comparison  of 
the  GRADUAL  and  ABRUPT  Groups  are  in  Appendix  K,  in  the  data 
section  of  the  SAS  control  file.  The  project  cost  estimate 
decision  data  for  Groups  GRADUAL  and  ABRUPT  are  in  Appendix  L, 
in  the  data  section  of  the  SAS  control  file. 

1.  Staffing  Level  Decisions 

The  mean  staffing  level  decisions  for  each  time  period 
by  group  are  plotted  in  Figure  4-1.  The  patterns  of  staffing 
decisions  identified  in  Figure  4-1  support  Hypothesis  la. 
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As  a  group,  those  subjects  presented  with  a  sudden 
increase  in  project  size  (ABRUPT  Group)  reacted  quickly  by 
increasing  staff  levels  by  a  significantly  larger  amount  than 
the  group  experiencing  a  gradual  increase  in  project  size. 
Additionally,  the  trend  after  the  initial  increase  was  one  of 
gradually  declining  levels,  and  an  earlier  completion  date 
(schedule) . 


STAFFING  LEVELS  vs  INTERVALS 

GRADUAL  AND  ABRUPT  GfWUPS 


Figure  4-1  Staffing  Level  Decisions 

In  contrast,  the  GRADUAL  Group  means  reflect  a  sharp 
Increase  in  staff  levels  through  the  second  time  period  (day 
80)  ,  a  slight  decrease  for  two  time  periods,  a  slight  rise  and 
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fall  in  the  next  two  time  periods,  and  then  a  drastic  increase 
at  Day  240,  followed  by  an  equally  drastic  decrease  at 
Day  320.  Analysis  of  the  raw  data  for  Day  280  revealed  a 
reduced  number  of  observations  being  averaged,  five  of  the 
subjects  having  already  completed  the  project.  Additionally, 
one  subject's  staffing  level  decision  (29  people)  at  Day  280 
skewed  the  entire  curve.  His  rationale  for  this  sudden 
increase  was,  "I  was  close  to  the  scheduled  completion  date, 
and  was  behind  in  tasks  reported  coit^lete,  so  I  doubled  my 
staffing  level."  The  "ADUSTED  GRADUAL  GROUP"  curve  on  the 
graph  shows  the  effect  of  his  decision  by  omitting  his 
decision  value  from  the  computation  of  the  interval's  mean 
staffing  level.  The  staffing  level  curve  then  continues  its 
slight  increase/decrease  tendency  which  began  at  Day  160 
through  the  final  interval  (Day  320) .  The  mean  completion 
date  for  Group  GRADUAL  was  approximately  forty  days  later  than 
that  of  Group  ABRUPT,  as  indicated  by  the  endpoints  of  the 
graph . 

Results  from  the  multivariate  analysis  of  variance 
performed  on  staffing  level  decisions  shown  in  Tedjle  4-1 
further  support  Hypothesis  la.  They  show  that  the  overall 
staffing  patterns  of  subjects  across  the  two  groups  were 
significantly  different  across  time  (P  <  0.05) .  There  was  no 
significant  between  subjects  effect;  overall  decisions  of 
subjects  were  not  significantly  different  across  the  two 
groups  (P  >  0.1) .  The  Within  Subjects  results  of  the  MANOVA 


shown  in  Table  4-1  support  the  findings  of  the  previous 
paragraph.  The  MANOVA  shows  significant  INTERVAL  effect 


TABLE  4-1  SUMMARY  OF  STAFFING  LEVEL  DECISIONS  REPEATED 
MEASURES  ANALYSIS' 


1  SOURCE  OF 

1  VARIATION 

s.s. 

d.f . 

F 

Sig  of  F 

1  BTWN  SUBJ 

B  Group 

24.4489 

1 

2.26 

0.1398 

1  Subj  w/in 
y  Group 

453.3894 

42 

W/IN  SUBJ 

Interval 

0.7426 

5,38 

2.6343 

0.0386 

Intvl*Grp 

0.6612 

5,38 

3.8936 

0.0060 

(P  <  0.05),  indicating  that  all  subjects  made  different 
decisions  as  time  evolved.  In  addition,  the  interaction,  or 
INTERVAL*GROUP  effect  is  significant  (P  <  0.05),  indicating 
that  the  pattern  of  the  decisions  made  differed  significantly 
over  time  between  the  two  groups. 

2.  Sxibjects'  Cost  Estimate  Decisions 

The  mean  cost  estimates  for  each  time  period  by  group 
are  plotted  in  Figure  4-2.  The  project  cost  estimates  for 
each  of  the  47  subjects  are  presented  in  Appendix  L  as  the 
data  section  of  the  SAS  control  file.  Cost  estimate  decision 


‘Degrees  of  freedom  are  reduced  because  of  the  number  of 
observations  ignored  by  the  Repeated  Measures  analysis  due  to 
missing  values  (subjects  had  already  completed  the  project) . 
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ESTIMATED  COST  vs  INTERVAL 


GRADUAL  A»C  ABRUPT  GROUPS 


INTERVAL  CDAVSJ 

a  GRADUAL  GP  COST  EST  +  ABRUPT  GP  COST  EST 


Figure  4-2  Cost  Estimate  Decisions 


patterns  identified  by  the  graph  support  Hypothesis  lb. 

The  mean  cost  estimates  for  each  group  closely 
parallel  each  other  until  after  Day  80,  when  the  ABRUPT  Group 
mean  estimate  jvut^s  sharply  while  the  GRADUAL  Group  mean 
continues  a  smooth  climb.  This  reflects  the  sudden  change  in 
project  size  just  revealed  to  the  ABRUPT  Group  managers. 
After  the  initial  sharp  increase,  the  ABRUPT  Group  managers 
lower  their  estimates  for  two  time  periods  in  a  row,  just  as 
the  GRADUAL  Group  managers  begin  to  increase  the  rate  of  their 
estimate  growth.  At  Day  200,  both  groups  increase  their 
estimates,  presumably  in  response  to  the  advent  of  the 
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scheduled  completion  date  in  three  time  periods.  However, 
GRADUAL  Group  maintains  a  consistent  increase  while  ABRUPT 
Group  increases  their  estimates  sharply,  as  they  had  after 
Day  80,  and  then  holds  the  estimate  steady  for  the  final  time 
period.  The  pattern  revealed  in  this  figure  shows  a  smooth, 
consistent  increase  in  the  GRADUAL  Group  estimate,  while  the 
ABRUPT  Group  is  characterized  by  abrupt,  spiky  increases  and 
decreases.  While  the  response  of  the  ABRUPT  Group  to  the 
sudden  increase  in  project  size  at  Day  100  is  obvious,  the 
reason  for  the  similar  increase  at  Day  200  is  less  so. 

Results  from  the  multivariate  analysis  of  variance 
performed  on  cost  estimate  decisions  shown  in  Table  4-2 
further  support  Hypothesis  lb  showing  that  the  overall  cost 

TABLE  4-2  SUMMARY  OF  COST  ESTIMATE  DECISIONS  REPEATED 
MEASURES  ANALYSIS^ 


SOURCE  OF 
VARIATION 

s.s. 

d.f . 

F 

Sig  of  F 

BTWN  SUBJ 

Group 

2238451.4 

1 

6.31 

0.0160 

Sub j  w/ in 
Group 

14908267 

42 

1  W/IN  SUBJ 

Interval 

0.3026 

5,38 

17.5114 

0.0001  1 

Intvl*Grp 

0.7083 

5,38 

3.1296 

0.0184  1 

*see  Footnote  1. 
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estimate  patterns  of  subjects  across  the  two  groups  were 
significantly  different  across  time  (P  <  0.05) .  There  was  a 
significant  between  subjects  effect;  within  a  given  interval, 
the  values  differed  significantly  between  groups  (P  <  0.05) 

The  Within  Subjects  results  of  the  MANOVA  shown  in  Table 
4-2  support  the  findings  of  the  previous  paragraph.  The 
MANOVA  shows  significant  INTERVAL  effect  (P  <  0.05), 

indicating  that  all  subjects  made  different  decisions  as  time 
evolved.  In  addition,  the  interaction,  or  INTERVAL* GROUP 
effect  is  significant  (P  <  0.05),  indicating  that  the  pattern 
of  the  decisions  made  differed  significantly  over  time  between 
the  two  groups. 

C.  PERFORMANCE  MEASURES  ANALYSIS  AND  RESULTS 

This  area  of  comparison  involves  the  final  cost  and 
schedule  for  each  group  (Groups  GRADUAL  and  ABRUPT)  as  a 
whole.  Table  4-3  shows  the  means  and  standard  deviation  of 
DIFFCOST,  DIFFSKED  and  COMBINED  DIFF.  These  values  show  that 
GRADUAL  Group  (gradual  increase  in  project  size)  has  a  higher 
mean  value  for  DIFFSKED,  indicating  that  they  were  farther 
from  the  initial  estimated  schedule  than  the  ABRUPT  Group 
(sudden  increase  in  project  size) ,  and  a  lower  mean  value  for 
DIFFCOST,  indicating  they  were  closer  to  the  original  cost 
estimate  than  the  ABRUPT  Group.  The  ABRUPT  Group  had  a  lower 
combined  difference  mean,  indicating  that,  on  average,  they 
were  closer  to  the  original  estimates  than  the  GRADUAL  Group. 


The  recurring  theme,  however,  is  that  regardless  of  how  the 
change  was  presented,  budget  was  forsaken  in  favor  of  meeting 
the  schedule. 

Results  of  the  MANOVA  performed  on  DIFFCOST  and  DIFFSKED 
are  shown  in  Table  4-4.  They  suggest  that  there  was  a 
significant  difference  in  performance  between  the  two  groups 
if  a  0.10  level  of  significance  is  applied  for  rejecting  the 


TABLE  4-3  PROJECT  COST  AND  SCHEDULE  MEANS  AND  STANDARD 
DEVIATION  BY  GROUP 


Group 

Variable 

MEAN 

STD  DEV 

GRADUAL 

DIFFCOST 

0.4736 

0.1105 

DIFFSKED 

0.0145 

0.1513 

COMBINED  DIFF 

0.2441 

0.0819 

ABRUPT 

DIFFCOST 

0.4962 

0.0908 

DIFFSKED 

-0.0930 

0.1607 

COMBINED  DIFF 

0.2016 

0.0752 

hypothesis.  If  a  more  strict  0.05  level  is  applied,  however, 
the  null  hypothesis  cannot  be  rejected.  The  results  suggest 
moderate,  but  not  strong  support  for  hypothesis  2. 


TABLE  4-4  MULTIVARIATE  ANALYSIS  OF  VARIANCE  FOR  SCHEDULE  AND 
COST 


1  Lambda 

df (num) 

df (den) 

F 

Sig  of  F  1 

1  0.8846 

2.94 

0.0634  1 
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The  results  of  the  univariate  analysis  of  variance  for 
DIFFSKED  in  Table  4-5  support  Hypothesis  2  in  terms  of 
schedule  (P  <  0.05).  However,  the  results  of  the  univariate 
analysis  of  variance  for  DIFFCOST  do  not  support  Hypothesis  2 
in  terms  of  cost  performance  (P  >  0.05)  .  A  univariate 
analysis  of  variance  was  also  performed  on  the  combined 


TABLE  4-5  UNIVARIATE  ANALYSIS  OF  VARIANCE  OF  COST,  SCHEDULE 
AND  COMBINED  DIFFERENCE 


VARIABLE 

CD 

CD 

• 

d.f . 

F 

Sig  of  F 

DIFFCOST 

0.0042 

1 

0.15 

0.7042 

DIFFSKED 

0.1135 

1 

4.53 

0.0387 

COMBINED 

0.0403 

1 

4.65 

0.0363 

differences  from  the  original  estimates,  COMBINED.  Results  of 
this  analysis  are  also  displayed  in  Table  4-5,  and  indicate 
strong  support  for  Hypothesis  2  (P  <  0.05) . 
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V.  CONCLUSIONS 


A.  SUMMARY  OF  FIMB:iNGS 

The  single-project  experiment  was  conducted  using  a 
properly  randomized  sample  population,  verified  by  statistical 
analysis  of  grade  distribution  of  the  the  subjects  in  their 
assigned  groups.  The  population  was  examined  for  outliers 
that  would  skew  the  results;  one  was  detected  and  deleted  from 
results  analysis.  The  specific  findings  of  the  experiment  are 
described  below.  The  measure  of  performance  is  defined  as  the 
ability  of  each  project  manager  to  meet  the  original  estimates 
of  time  and  schedule. 

•  Project  managers  of  a  system  which  roughly  doubles  in  size 
during  its  lifecycle  make  different  decisions  on  staffing 
and  cost  estimates  when  given  the  change  abruptly  than 
when  presented  with  the  change  in  gradual  increments. 

•  Project  managers  of  a  system  which  roughly  doxables  in  size 
during  its  lifecycle  perform  better  in  terms  of  cost  and 
schedule  when  given  the  change  abruptly  than  when 
presented  with  the  change  in  gradual  increments. 

In  all  cases,  the  deviation  of  the  final  schedule  from  the 
original  schedule  was  less  than  the  deviation  of  the  final 
cost  from  the  original  cost,  indicating  that  if  sufficient 
staff  resources  are  availeUsle,  managers  will  jeopardize 
maintaining  budget  goals  in  order  to  achieve  a  given  schedule. 


The  decision  trends  of  the  groups  indicate  that  the 
GRADUAL  groups  reacted  more  slowly  to  the  changes  in  size, 
using  fewer  resources  initially  and  increasing  both  staff  size 
and  cost  estimates  rapidly  near  the  end  of  the  lifecycle. 
The  ABRUPT  group  displayed  a  tendency  to  use  greater  resources 
upon  learning  of  the  change  in  size,  and  decreasing  staff  size 
and  cost  estimates  near  the  end  of  the  lifecycle. 

B .  IMPLICATIONS 

Use  of  resources  depends  as  much  on  the  knowledge  of  when 
and  how  many  resources  will  be  required  as  on  the  knowledge  of 
the  task  to  be  performed.  Although  our  knowledge  of  a 
project's  complexity  and/or  size  may  be  imperfect,  the  more 
information  we  have  about  the  scope  of  the  project  early  on, 
and  about  its  actual  progress  will  improve  the  performance  and 
efficiency  of  the  project.  Although  the  reactions  of  the 
ABRUPT  group  were  more  pronounced  than  those  of  the  GRADUAL 
group,  the  end  result  was  improved  performance  in  terms  of 
schedule,  if  not  cost  as  well. 

C.  FUTURE  RESEARCH  EFFORTS 

System  dynamics  and  its  effects  on  project  management  are 
of  crucial  importance  in  understanding  and  improving  processes 
and  performance.  Use  of  the  SDM  gaming  interface  to 
investigate  the  effects  of  improved  visibility,  estimates  and 
reporting  procedures  lends  itself  to  several  research  efforts. 
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A  logical  followup  to  this  experiment  would  be  to  examine  the 
effects  of  improved  visibility  at  early-,  mid-  and  late- 
intervals  in  the  lifecycle  of  the  project  to  determine  where 
it  is  crucial,  where  it  is  helpful,  and  where  it  is 
deleterious  to  the  success  of  the  project. 
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APPENDIX  A:  TEST  DYNEX  FILE 


if  #tm<0.9  then 
display  clear 


*********  EXPERIMENT  TRIAL  RUN  ********* 

Important  Points  to  Remember  !!!!!!!!! 

************************************** 


-  You  are  not  allowed  to  discuss  this  exercise  with  anyone 
other  than  a  lab  attendant.  Please  refrain  from  discussing 
this  with  other  class  members  until  they  have  completed  the 
project. 

-  The  system  will  run  through  the  first  simulation  period 
(2  months)  and  provide  you  with  a  status  report.  At  the  end 
of  each  reporting  period,  you  will  have  an  opportunity  to 
revise  the  estimated  total  project  cost  (in  man  days) ,  and  to 
revise  your  desired  staff  level. 

-  In  this  trial  run,  you  do  not  have  to  annotate  the 
documentation  sheet.  Use  the  trial  run  for  two  time  periods 
to  familiarize  yourself  with  the  e3<periment  procedures. 

-  Press  <ENTER>  to  continue 
dendq 

choice  1 
cend  1/1 
else 

choice  1 
cend  1/1 
display  clear 

INPUT  YOUR  ESTIMATE  OF  THE  TOTAL  PROJECT  COST  IN  MAN 

DAYS 

*********************************************************** 


1)  Press  <ENTER>  to  maintain  your  last  cost  estimate 


*****  OR  ***** 

2)  Enter  your  new  estimate  of  total  project  cost  (in 
man  days) 

and  press  <ENTER>. 
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Your  last  project  cost  estimate  was  = 

dendq 

dq  TOTMD1=0<100000 
display  clear 


! 1 ! ! 1 !  !  !  WARNING  !!!!!!!< 

Make  sure  that  you  have  written  your  project  cost 
estimate  down  on  the  project  documentation  sheet 
before  continuing  with  the  simulation - 

This  is  your  final  chance  to  change  your  estimated 
total  project  cost.  Press  <ENTER>  to  keep  the  same 
estimate  or  enter  a  new  cost  estimate  and  then  press 
< ENTER >. 

The  updated  estimate  of  total  project  cost  is  = 

dendq 

dq  TOTMD1=0<100000 
display  clear 


INPUT  YOUR  DESIRED  STAFFING  LEVEL 

*********************************** 


1)  Press  <ENTER>  to  maintain  your  last  desired  staffing 
level . 

*********  OR  ********* 

2)  Enter  the  new  desired  staffing  level  and  press 
< ENTER > . 


Your  last  desired  staffing  level  was  = 
dendq 

dq  WFSl-  0<100 
display  clear 


II!! IWARNING! ! ! ! ! 

Make  sure  that  you  have  written  your  staffing 
level  decision  down  on  the  project  documentation 
sheet  before  continuing  with  the  simulation. 
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This  is  your  final  chance  to  change  your 
staffing  level  for  this  time  period.  Press 
<ENTER>  to  keep  the  same  niimber  or  enter  a 
new  staffing  level  and  press  <ENTER>. 


The  current  staffing  level  = 
dendg 

dq  WFS1=  0<100 
end 

display  clear 

Press  <ENTER>  to  simulate  the  next  time  interval. 

dendq 
choice  1 
REPORT 

time=maxtime, 

FORMAT="40- " 

"PROJECT  STATUS  REPORT";; 
Format<="20<,54<,66<",PICTURE="Z,ZZ9V" 

"ELAPSED  TIME  ========  =>" , tm, "Days" ; ; 

Format="5<" 

"ESTIMATES  MADE  AT  THE  START  OF  THE  PROJECT"; 

FORMAT= " 8< , 52< , 66c " , PICTURE= "ZZZ, ZZZV" 

"Project  Size" , IPRJSZ, "Tasks" ; 

FORMAT* " 8< , 52< , 66< " , PICTURE* " ZZZ, ZZZV" 

"Project  Cost  in  Man  Days ", TOTMDO , "Man  Days"; 

F0RMAT*"8< , 52< , 66< " , PICTURE* "ZZZ, ZZZV" 

"Project  Duration" ,TDEV1, "Days" ; 

Format* " 5< , 52< ,66c", PICTURE* "ZZZ, ZZ9V" 

"PROJECT  STATUS  at  Time  ===========  =>" , tm, "Days " ; 

FORMAT* " 8c , 52c , 66c " , PICTURE* " ZZZ, ZZ9V. 99 " 

"Updated  Estimate  of  Total  Project  Size" , PJBSZ, "Tasks" ; 
FORMAT* " 8c , 52c , 66c ",  PICTURE* " ZZZ , ZZ9V . 99 " 

"%  Development  (Design  &  Code)  Reported 
Complete " , PDVRC , " Percent " ; 

FORMAT* " 8c , 52c , 66c  ",  PICTURE* "ZZZ, ZZ9V. 99 " 

"%  Testing  Reported  Compl ete",PTKTST*l 00, "Percent" ; 

FORMAT* " 8 c , 52 c , 6 6 c " , PICTURE* " ZZZ , ZZ9V . 9 9 " 

"Updated  Estimate  of  Total  Man  Days" ,JBSZMD, "Man  Days"; 
FORMAT* "8c, 52c, 66c" , PICTURE* "ZZZ, ZZZV. 99 " 

"Total  Man  Days  Expended  to  date" ,CUMMD, "Man  Days"; 

FORMAT* " 8c , 52c , 66c " , PICTURE* "ZZZ, ZZ9V" 

"Updated  Est.  of  Project  Duration  (start-end) ",SCHCDT, "Days"; 
FORMAT- "8c , 52c , 66c " , PICTURE* "ZZZ, ZZ9V. 9 " 

"Current  Staff  Size" , FTEQWF, "Fulltime  Staff"; 

FORMAT* "5c" 

"PRESS  cENTER>  TO  RETURN  TO  MENU" 
cend  1/1 

spec  md_length-#length+40 
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APPENDIX  B:  EXPl  DYNEX  FILE 


if  #tin<0.9  then 
display  clear 


Important  Points  to  Remember  !!!!!!!!! 

-  You  are  not  allowed  to  discuss  this  exercise  with  anyone 
other  than  a  Icib  attendant.  Please  refrain  from  discussing 
this  with  other  class  members  until  they  have  completed  the 
project . 

-  The  system  will  run  through  the  first  simulation  period 
(2  months)  and  provide  you  with  a  status  report.  At  the  end 
of  each  reporting  period,  you  will  have  an  opportunity  to 
revise  the  estimated  total  project  cost  (in  man  days) ,  and  to 
revise  your  desired  staff  level. 

-Make  your  changes  to  the  cost  estimate  and  the  desired 
staffing  level  both  on  the  documentation  sheet  provided  and  on 
the  screen. 

A  LAB  ATTENDANT  MUST  VERIFY  YOUR  FINAL  RESULTS! 

-  GOOD  LUCK!  Press  <ENTER>  to  continue, 
dendg 

choice  1 
cend  1/1 
else 

choice  1 
cend  1/1 

display  clear 


INPUT  YOUR  ESTIMATE  OF  THE  TOTAL  PROJECT  COST  IN  MAN 

DAYS 

*********************************************************** 


1)  Press  <ENTER>  to  maintain  your  last  cost  estimate 

********  OR  ******** 
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2) 

days) 


Enter  your  new  estimate  of  total  project  cost  (in  man 
and  press  <ENTER> 


Your  last  project  cost  estimate  was  = 
dendg 

dq  TOTMD1=0<100000 
display  clear 


!!!!!!!!  WARNING  !!!!!!!! 


Make  sure  that  you  have  written  down  your  project 
cost  estimate  down  on  the  project  documentation 
sheet  before  continuing  with  the  simulation. 

This  is  your  final  chance  to  change  the  estimated 
total  project  cost.  Press  <ENTER>  to  keep  the  same 
estimate  or  enter  a  new  cost  estimate  and  then  press 
< ENTER > . 

The  updated  estimate  of  total  project  cost  is  = 
dendg 

dq  TOTMD1=0<100000 
display  clear 


INPUT  YOUR  DESIRED  STAFFING  LEVEL 


1)  Press  <ENTER>  to  maintain  your  last  desired  staffing 
level . 

*********  OR  ********* 

2)  Enter  the  new  desired  staffing  level  and  press 
<ENTER>. 

Your  last  desired  staffing  level  was  » 
dendg 

dq  WFSl-  0<100 
display  clear 


! ! ! I 1WARNIN6! 1 ! ! ! 

Make  sure  that  you  have  written  your  staffing 
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level  decision  down  on  the  project  documentation 
sheet  before  continuing  with  the  simulation. 

This  is  your  final  chance  to  change  your 
staffing  level  for  this  time  period.  Press 
<ENTER>  to  keep  the  same  number  or  enter  a 
new  staffing  level  and  press  <ENTER>. 


The  current  staffing  level  = 
dendg 

dq  WFS1»  0<100 
end 

display  clear 

Press  <ENTER>  to  simulate  the  next  time  interval . 

dendq 
choice  1 
REPORT 

t  ime^Einaxt  ime , 

FORMAT- " 40 

"PROJECT  STATUS  REPORT";; 

Format- "20< , 54< , 66< " , PICTURE- " Z, ZZ9V" 

"ELAPSED  TIME  ========  ->",tm,"Days";; 

Format- "5<" 

"ESTIMATES  MADE  AT  THE  START  OF  THE  PROJECT"; 

FORMAT-" 8< , 52< , 66< " , PICTURE- "ZZZ, ZZZV" 

"Project  Size" , IPRJSZ, "Tasks" ; 

FORMAT- "8<,52<,66<", PICTURE- " ZZZ , ZZZV " 

"Project  Cost  in  Man  Days" ,TOTMDO, "Man  Days"; 

FORMAT- "8<, 52<, 66<" , PICTURE="ZZZ, ZZZV" 

"Project  Durat ion ",TDEVl, "Days"; 

Format- "5< , 52< , 66<" , PICTURE- "ZZZ, ZZ9V" 

"PROJECT  STATUS  at  Time  ===»=====-=  =>",tm,"Days"; 
FORMAT-" 8< , 52< , 66< ",  PICTURE- "ZZZ, ZZ9V. 99 " 

"Updated  Estimate  of  Total  Project  Size" , PJBSZ, "Tasks" ; 
FORMAT- "8<,52<,66<", PICTURE- "ZZZ, ZZ9V. 99 " 

"%  Development  (Design  &  Code)  Reported 
Complete " , PDVRC , " Percent " ; 

FORMAT- "8<,52<,66<", PICTURE- " ZZZ , ZZ9 V .99" 

"%  Testing  Reported  Complete" ,PTKTST* 100, "Percent" ; 

FORMAT- " 8< , 52< , 66< " , PICTURE- "ZZZ, ZZ9V. 99 " 

"Updated  Estimate  of  Total  Man  Days" ,JBSZMD, "Man  Days"; 
FORMAT- " 8< , 52< , 66< ",  PICTURE- " ZZZ, ZZZV . 99 " 

"Total  Man  Days  Expended  to  date",CUMMD, "Man  Days"; 

FORMAT- "8< , 52< , 66< " , PICTURE- "ZZZ, ZZ9V" 

"Updated  Est.  of  Project  Duration  (start-end) " ,SCHCDT, "Days" ; 
FORMAT- " 8< , 52< , 66< " , PICTURE- "ZZZ , ZZ9V . 9 " 

"Current  Staff  Size" , FTEQWF, "Fulltime  Staff"; 

FORMAT- "5<" 

"PRESS  <ENTER>  TO  RETURN  TO  MENU" 
cend  1/1 

spec  md_length«#length+40 
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APPENDIX  Ct  EZP2  DYNBX  FILE 


if  #tm<0.9  then 
display  clear 


Important  Points  to  Remember  !!!!!!!!! 

-  You  are  not  allowed  to  discuss  this  exercise  with  anyone 
other  than  a  lab  attendant.  Please  refrain  from  discussing 
this  with  other  class  members  until  they  have  completed  the 
project. 

-  The  system  will  run  through  the  first  simulation  period 
(2  months)  and  provide  you  with  a  status  report.  At  the  end 
of  each  reporting  period,  you  will  have  an  opportunity  to 
revise  the  estimated  total  project  cost  (in  man  days) ,  and  to 
revise  your  desired  staff  level. 

-  Make  your  change  to  the  desired  staffing  level  both  on 
the  documentation  sheet  provided  and  on  the  screen. 

A  LAB  ATTENDANT  MUST  VERIFY  YOUR  FINAL  RESULTS! 

-  GOOD  LUCK!  Press  <ENTER>  to  continue, 
dendq 

choice  1 
cend  1/1 
else 

choice  1 
cend  1/1 
display  clear 

INPUT  YOUR  ESTIMATE  OF  THE  TOTAL  PROJECT  COST  IN  MAN  DAYS 

*********************************************************** 


1)  Press  <ENTER>  to  maintain  your  last  cost  estimate 

*****  OR  ***** 


2)  Enter  your  new  estimate  of  total  project  cost  (in 
man  days) 

and  press  <ENTER>. 
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Your  last  project  cost  estimate  was  = 

dendq 

dq  TO™d1-0<100000 
display  clear 


!!!!!!!!  WARNING  !!!!!!!! 

Make  sure  that  you  have  written  your  project  cost 
estimate  down  on  the  project  documentation  sheet 
before  continuing  with  the  simulation. 

This  is  your  final  chance  to  change  your  estimated 
total  project  cost.  Press  <ENTER>  to  keep  the  same 
estimate  or  enter  a  new  cost  estimate  and  then  press 
<ENTER> . 


The  updated  estimate  of  total  project  cost  is  = 

dendq 

dq  TOTMD1=0<100000 
display  clear 


INPUT  YOUR  DESIRED  STAFFING  LEVEL 

*********************************** 


1)  Press  <ENTER>  to  maintain  your  last  desired  staffing 
level . 

*********  OR  ********* 

2)  Enter  the  new  desired  staffing  level  and  press 
< ENTER > . 


Your  last  desired  staffing  level  was  = 
dendq 

dq  WFSl-  0<100 
display  clear 


I! ! ! {WARNING! ! ! ! ! 

Make  sure  that  you  have  written  your  staffing 
level  decision  down  on  the  project  documentation 
sheet  before  continuing  with  the  simulation. 
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This  is  your  final  chance  to  change  your 
staffing  level  for  this  time  period.  Press 
<ENTER>  to  keep  the  same  nxarober  or  enter  a 
new  staffing  level  and  press  <ENTER>. 


The  current  staffing  level  = 
dendg 

dq  WFS1=  0<100 
if  #tm  <80  then 
display  clear 

Press  <ENTER>  to  simulate  the  next  time  interval. 

dendq 

else 

if  #tm<120  then 
display  clear 
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****  SPECIAL  REPORT  FOLLOWS  **** 

PRESS  <ENTER>,  THEN  READ  CAREFULLY! 


dendq 
choice  1 
cend  1/1 
display  clear 
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!  !  !  !  ! 


YOUR  PROJECT  SIZE  JUST  INCREASED  BY  54% ! 


THE  PREVIOUS  PROJECT  SIZE  WAS  #PJBSZ  TASKS 

THE  CURRENT  PROJECT  SIZE  IS  609  TASKS 

Press  <ENTER>  to  continue  .  .  . 


dendq 
choice  1 
cend  1/1 
display  clear 

Press  <ENTER>  to  simulate  the  next  time  interval. 

dendq 

else 

end 

end 

end 

display  clear 

Press  <ENTER>  to  simulate  the  next  time  interval . 

dendq 
choice  1 
REPORT 

t  ime^mcuct  ime , 

FORMAT* " 40 

"PROJECT  STATUS  REPORT";; 

Format- "20<,54<,66<",PICTURE="Z,ZZ9V" 

"ELAPSED  TIME  ====*«==  ->" , tm, "Days" ; ; 

Format- "5<" 

"ESTIMATES  MADE  AT  THE  START  OF  THE  PROJECT"; 

FORMAT- "8< , 52< , 66< " , PICTURE- "ZZZ, ZZZV" 

"Project  Size",IPRJSZ,"Tasks"; 

FORMAT- " 8< , 52 <, 66< ",  PICTURE- " ZZZ, ZZZV" 
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"Project  Cost  in  Man  Days ", TOTMDO , "Man  Days"; 

FORMAT= "8<,52<,66<", PICTURE= " ZZZ , ZZZV " 

"Project  Duration" ,TDEV1, "Days" ; 

Format* "5< , 52<, 66<" , PICTURE* " ZZZ, ZZ9V" 

"PROJECT  STATUS  at  Time  ===========  =>" , tm, "Days" ; 

FORMAT= "8<,52<,66<", PICTURE* " ZZZ , ZZ9V . 99 " 

"Updated  Estimate  of  Total  Project  Size" , PJBSZ, "Tasks" ; 
FORMAT* " 8< , 52< , 66< " , PICTURE* " ZZZ, ZZ9V. 99 " 

"%  Development  (Design  &  Code)  Reported 
Complete" , PDVRC, "Percent" ; 

FORMAT* " 8< , 52< , 66< " , PICTURE* "ZZZ, ZZ9V. 99 " 

"%  Testing  Reported  Complete" , PTKTST* 100, "Percent" ; 

FORMAT* " 8< , 52 < , 6 6 < " , PICTURE* " ZZZ , ZZ9V . 9 9 " 

"Updated  Estimate  of  Total  Man  Days" ,JBSZMD, "Man  Days"; 
FORMAT* "8< , 52< , 66< ",  PICTURE* "ZZZ, ZZZV. 99 " 

"Total  Man  Days  Expended  to  date" , CUMMD, "Man  Days"; 

FORMAT* ''8< ,  52<,  66< "  ,  PICTURE* " ZZZ,  ZZ9V" 

"Updated  Est.  of  Project  Duration  (start-end)",SCHCDT,"Days"; 
FORMAT* " 8<, 52<, 66<", PICTURE* "ZZZ, ZZ9V. 9" 

"Current  Staff  Size" , FTEQWF, "Fulltime  Staff"; 

FORMAT* "5<" 

"PRESS  <ENTER>  TO  RETURN  TO  MENU" 
cend  1/1 

spec  md_length*#length+40 


45 


APPENDIX  Dt  TEST  BATCH  CONTROL  FILE 


echo  off 
CLS 

init  1 
GRAPHICS 
bat  /N  /p  /s 

emit  TEST  -go  =  -prs  *  -Is  -ns  -plm  6  -bw 

-top  dynex  TEST  -in  TEST.STT  -sc  -Is  -plm  6  -bw 
smlt  TEST  -gm  =  -ns  -plm  6  -bw 
rep  TEST  -outf  INTERVAL .OUT  -t  -bw  >NUL 
rep  TEST  -bw  >NUL 
infoofb  1 
Call  -topi 
Exit 

goto  -top%A 

-topi  %A  =  1 

color  \1F 

ram 

els 

begtype 


MAIN  MENU 


\1F  ENSURE  YOU  HAVE  VIEWED  THE  PROJECT  STATUS 

REPORT 

\1F  FOR  THIS  TIME  PERIOD  PRIOR  TO  SELECTING  OPTION 

#2 

\1D  1  \1F  VIEW  PROJECT  STATUS  REPORT 

\1D  2  \1F  PROCEED  TO  SIMULATE  NEXT  TIME 

PERIOD 

Choose  an  option: \1C  DO  NOT  HIT  <ENTER>  AFTER  SELECTION! !)  ; 

end 


-Istkeyl  inkey  %0  |  if  %0  #  *  l  type  %0; 
if  %0  *  keyOlb  return 
goto  -%0~1 
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-2ndkeyl  inkey  %1  j  if  %1  #  =  1  type  %1; 
if  %1  =  keyOlb  return 
if  %1  =  key020  goto  -$%0$1 
if  %1  =  keyOOd  goto  -$%0$1 
if  %1  =  keyOOS  goto  -topi 
if  %1  =  keyl4b  goto  -topi 
goto  -%0%11 

-1~1  ****  VIEW  PROJECT  STATUS  REPORT  ******************** 

rep  TEST  TEST  -outf  TEST. OUT  -t  -SC  Is  -plm  6  -bw 
INKEY  %0 

bat  /p  /s  goto  -topi 

-2~1  ****  PROCEED  WITH  NEXT  SIMULATION  ******************** 

BAT  CLS 
BAT  COLOR  \1F 
BAT  BEGTYPE 

*****1i*****1t****1t*1i*1i**1t*1t***1t*1fk1t*1t1c**it*±*1t********1t****1t** 


1.  DETERMINE  YOUR  ESTIMATE  OF  TOTAL  PROJECT  COST  (IN 
MAN  DAYS)  AND  WRITE  IT  ON  THE  DOCUMENTATION  SHEET. 

2.  DETERMINE  YOUR  DESIRED  STAFFING  LEVEL  AND  WRITE  IT 
ON  THE  DOCUMENTATION  SHEET. 

3 .  PRESS  <ENTER> . 


*1fk****1r1r**1c*1c**1t*1c***1i*1i*1t*************1i****************1r**- 

9 

END 

bat  /p  /s  goto  -top 

-%0~1 

-$%0$1 

-%0%ll  beep  goto  -topi 
-on.error- 

if  %R  >  82  if  %R  <  90  type  !!  Floating  Point  Error  !!  |goto 
-Calc. 

Cls  beep  type  Unexpected  batch  file  error  %R  in  line  %L  |exit 
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APPENDIX  E:  EXPl  BATCH  CONTROL  FILE 


echo  off 
CLS 

init  1 
GRAPHICS 
bat  /N  /p  /s 

smlt  EXPl  -go  =  -prs  =  -Is  -ns  -plm  6  -bw 

-top  dynex  EXPl  -in  EXPl.STT  -sc  -Is  -plm  6  -bw 
smlt  EXPl  -gm  =  -ns  -plm  6  -bw 
rep  EXPl  -outf  INTERVAL. OUT  -t  -bw  >NUL 
rep  EXPl  -bw  >NUL 
infoofb  1 
Call  -topi 
Exit 

goto  -top%A 

-topi  %A  =  1 

color  \1F 

ram 

els 

begtype 


\1A  MAIN  MENU 


\1F  ENSURE  YOU  HAVE  VIEWED  THE  PROJECT  STATUS  REPORT 

\1F  FOR  THIS  TIME  PERIOD  PRIOR  TO  SELECTING  OPTION  #2 


\1D  1  \1F  VIEW  PROJECT  STATUS  REPORT 

\1D  2  \1F  PROCEED  TO  SIMULATE  NEXT  TIME  PERIOD 

Choose  an  option;  \1C  DO  NOT  HIT  <ENTER>  AFTER 
SELECTION! I ) 
end 

-Istkeyl  inkey  %0  |  if  %0  #  =  l  type  %0; 
if  %0  =  keyOlb  return 
goto  -%0~l 

-2ndkeyl  inkey  %1  |  if  %l  #  =  1  type  %1; 
if  %1  =  keyOlb  return 
if  %1  =  key020  goto  -$%0$1 
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if  %1  =  keyOOd  goto  -$%0$1 
if  %1  =  keyOOS  goto  -topi 
if  %1  =  keyl4b  goto  -topi 
goto  -%0%11 

-1~1  ****  VIEW  PROJECT  STATUS  REPORT  ******************** 

rep  EXPl  EXPl  -outf  EXPl.OUT  -t  -sc  -Is  -plm  6  -bw 
INKEY  %0 

bat  /p  /s  goto  -topi 

-2~1  ****  PROCEED  WITH  NEXT  SIMULATION  ******************** 

BAT  CLS 
BAT  COLOR  \1F 
BAT  BEGTYPE 


It*********************************************************** 

***** 

1.  DETERMINE  YOUR  ESTIMATE  OF  TOTAL  PROJECT  COST  (IN 
MAN  DAYS)  AND  WRITE  IT  ON  THE  DOCUMENTATION  SHEET. 

2.  DETERMINE  YOUR  DESIRED  STAFFING  LEVEL  AND  WRITE  IT 
ON  THE  DOCUMENTATION  SHEET. 

3 .  PRESS  <ENTER> . 


************************************************************ 

♦****• 

/ 

END 

bat  /p  /s  goto  -top 

-%0~1 

-$%0$1 

-%0%ll  beep  goto  -topi 
-on. error - 

if  %R  >  82  if  %R  <  90  type  !!  Floating  Point  Error  !!  |goto 
-Calc. 

Cls  beep  type  Unexpected  batch  file  error  %R  in  line  %L  [exit 
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APPENDIX  F:  EXP2  BATCH  CONTROL  FILE 


echo  off 
CLS 
init  1 
GRAPHICS 
bat  /N  /p  /s 

emit  EXP2  -go  *  -prs  =  -Is  -ns  -plm  6  -bw 

-top  dynex  EXP2  -in  EXP2.STT  -sc  -Is  -plm  6  -bw 
smlt  EXP2  -gm  =  -ns  -plm  6  -bw 
rep  EXP2  -outf  INTERVAL. OUT  -t  -bw  >NUL 
rep  EXP2  -bw  >NUL 
infoofb  1 
Call  -topi 
Exit 

goto  -top%A 

-topi  %A  =  1 

color  \1F 

ram 

els 

begtype 


\1A  MAIN  MENU 


\1F  ENSURE  YOU  HAVE  VIEWED  THE  PROJECT  STATUS  REPORT 

\1F  FOR  THIS  TIME  PERIOD  PRIOR  TO  SELECTING  OPTION  #2 


\1D  1  \1F  VIEW  PROJECT  STATUS  REPORT 

\1D  2  \1F  PROCEED  TO  SIMULATE  NEXT  TIME  PERIOD 

Choose  an  option: \1C  DO  NOT  HIT  <ENTER>  AFTER  SELECTION! !)  ; 

end 

-istkeyl  inkey  %0  |  if  %0  #  *  1  type  %0; 
if  %0  -  keyOlb  return 
goto  -%0~1 

-2ndkeyl  inkey  %1  |  if  %1  #  =  1  type  %1; 
if  %1  »  keyOlb  return 
if  %1  =  key020  goto  -$%0$1 
if  %1  ■  keyOOd  goto  -$%0$1 
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if  %1  =  keyOOS  goto  -topi 
if  %1  =  keyl4b  goto  -topi 
goto  -%0%11 


-1~1  ****  VIEW  PROJECT  STATUS  REPORT  ******************** 

rep  EXP2  EXP2  -outf  EXP2.0UT  -t  -SC  -Is  -plm  6  -bw 
INKEY  %0 

bat  /p  /s  goto  -topi 

-2-1  ****  PROCEED  WITH  NEXT  SIMULATION  ******************** 

BAT  CLS 
BAT  COLOR  \1F 
BAT  BEGTYPE 


************************************************************ 

1.  DETERMINE  YOUR  ESTIMATE  OF  TOTAL  PROJECT  COST  (IN 
MAN  DAYS)  AND  WRITE  IT  ON  THE  DOCUMENTATION  SHEET. 

2.  DETERMINE  YOUR  DESIRED  STAFFING  LEVEL  AND  WRITE  IT 
ON  THE  DOCUMENTATION  SHEET. 

3 .  PRESS  <ENTER> 


************************************************************* 

END 

bat  /p  /s  goto  -top 

-%0~1 

-$%0$1 

-%0%ll  beep  goto  -topi 
- on. error - 

if  %R  >  82  if  %R  <  90  type  !!  Floating  Point  Error  !!  |goto 
-Calc. 

Cls  beep  type  Unexpected  batch  file  error  %R  in  line  %L  |exit 
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APPENDIX  G:  EXPERIMENT  DOCUMENTATION  AND  INSTRUCTION  SET 


YOUR  NAME: 
SMC  NO; 


INTRODUCTION 

The  exercise  you  are  about  to  undertake  is  similar  in  many 
ways  to  the  flight  simulators  that  pilots  use  to  mimic  flying 
an  aircraft  from  takeoff  at  point  A  to  landing  at  point  B. 
Instead  of  the  flight  of  an  aircraft,  though,  this  simulator 
mimics  the  life  of  a  real  software  project  from  the  start  of 
the  design  phase  until  the  end  of  testing.  In  this 
simulation,  you  will  be  more  than  an  observer.  In  fact,  you 
will  play  an  important  role  on  the  project:  that  of  the 
project  manager. 

Specifically,  your  role  will  be  to  track  the  project's 
progress  using  a  niunber  of  status  reports  that  will  be 
produced  for  you  at  two -month  intervals  (40  working  days) 
during  the  project.  As  the  project  manager,  you  must  then 
update  the  project's  total  cost  estimate  as  well  as  determine 
the  staff  size  based  on  the  Jtnowledge  you  gain  from  these 
reports.  You  can  hire  additional  staff  or  decrease  the 
staffing  level  as  you  deem  necessary  to  complete  the  project. 


PROJECT 

The  project  that  you  will  manage  happens  to  have  been  a 
real  project  conducted  in  a  real  organization.  The  particular 
organization  is  on  the  leading  edge  in  software  engineering 
technology.  For  the  project,  you  will  be  given  a  project 
profile  containing  the  following  initial  information: 

Estimated  Project  Size (in  Number  of  Tasks*) 

Estimated  Duration (in  Number  of  Work  Days) 

Estimated  Project  Cost  (in  Ntunber  of  Man  Days) 

Size  of  Initial  Core  Team**  (in  Nvunber  of  People) 

*  A  task  is  a  software  module  that  is  approximately  50 
lines  of  code  in  size. 

**  The  Core  Team  is  the  group  of  software  professionals 
that  developed  the  project's  requirement  specifications. 
(Remember,  you  are  taking  over  at  the  beginning  of  the 
Design  Phase) . 
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YOUR  TASK 


Your  task  is  to  use  the  bi-monthly  status  reports  to 
update  the  project's  total  cost  estimate  (in  man  days)  and 
to  determine  a  desired  staffing  level  for  the  remainder  of 
the  project.  Your  objective  in  setting  the  staffing  level 
should  be  to  complete  the  project  on  schedule. 

Note,  however,  that  finishing  ahead  of  schedule  will  not 
gain  you  anything.  In  fact,  it  may  hurt  you,  since 
finishing  ahead  of  schedule  will  probably  mean  hiring  more 
staff  than  needed,  thus  incurring  a  higher  cost  than 
required. 


SOME  IMPORTANT  THINGS  TO  COKSIDBR  IN  MAKING  YOUR  ESTlMRTESi 

1.  This  simulation  mimics  reality  very  closely.  As  real 
managers  often  do,  you  will  have  to  use  your  ~iudaement  in 
coming  up  with  your  estimates. 

2 .  As  you  ponder  whether  or  not  you  should  update  the 
project's  cost  (in  man  days),  you  will  be  relying  on  the 
status  report  information.  This  will  provide  you,  for 
example,  with: 

(a)  Updated  Estimate  of  Total  Project  Size  (in  Tasks) 

(b)  %  Development  (Design  and  Code)  Reported  Complete 
(Percent) 

(c)  Total  Man  Days  Expended  to  Date  (Man  Days) 

3.  As  part  of  your  task,  you  will  specify  the  desired 
staffing  level  for  the  remainder  of  the  lifecycle.  You  may 
find  that  the  actual  staff  level  may  be  somewhat  different. 
This  will  be  due  to  things  you  cannot  totally  control  such 
as  turnover  and  lengthy  hiring  delays. 

(a)  The  personnel  turnover  rate  is  20%  per  year. 

(b)  The  hiring  delay  for  new  employees  can  take  up  to  6 
weeks.  Once  new  people  are  hired,  the  training  period  for  a 
newly  hired  employee  is  typically  one  month  long.  This  is 
the  time  needed  to  train  a  new  employee  in  the  mechanics  of 
the  project  and  bring  him/her  up  to  speed.  A  new  employee 
(i.e.  one  that  is  being  trained)  is  only  half  as  productive 
as  an  experienced  employee. 

4.  At  different  points  in  the  project  you  will  be  given 
information  on  the  status  of  the  project.  Three  key  pieces 
of  information  for  your  task  are: 
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(a)  The  "I]t>dated  Estimate  of  Total  Project  Size"  (this 
can  change  to  reflect  the  addition  of  new  requirements) . 


(b)  The  "Total  Man  Days  Esqpended  to  Date".  Subtracting 
the  "Total  Man  Days  Expended  to  Date"  from  your  "Updated 
Estimate  of  Total  Man  Days"  yields  the  "Remaining  Effort 
in  Man  Days."  For  example,  if  your  "Updated  Estimate  of 
Total  Man  Days"  is  1000  days,  and  the  "Man  Days  Expended 
to  Date"  figure  is  300  days,  the  Remaining  Effort  is  700 
man  days. 

(c)  The  "Updated  Estimate  of  Project  Duration  (start- 
end)  "  .  In  order  to  determine  the  "Remaining  Time",  you 
subtract  the  "Elapsed  Time"  from  the  "Updated  Estimate 
of  Project  Duration  (start-end)."  For  exaitple,  if  the 
"Updated  Estimate  of  Project  Duration  (start -end) "  is 
200  days,  and  the  "Elapsed  Time"  is  80  days,  the 
Remaining  Time  is  120  days.  It  is  important  to  note 
that  this  is  an  estimate  which  may  or  may  not  be  totally 
reliable. 

This  information  could  help  you  figure  out,  on  the  one  hand, 
the  number  of  tasks  remaining,  and  on  the  other,  your  team's 
productivity  (i.e.,  tasks  developed  per  man  day).  But .  you 
must  remember  that  in  this  project  (like  in  real  projects) , 
such  status  information  (e.g.,  percent  reported  complete) 
may  or  may  not  be  totally  reliadsle.  Typically,  such  status 
reports  are  not  completely  reliable  in  the  earlier  phases. 
However,  as  the  project  proceeds,  visibility  typically 
improves  and  with  it,  the  relisUsility  of  information.  The 
bottom  line  is;  You  will  have  to  use  your  best  judgement. 

5.  As  many  projects  do,  the  size  of  your  project  may  change 
as  the  project  proceeds  (e.g.,  to  reflect  changes  in  user 
requirements) .  Again,  you  will  have  to  use  your  judgement 
in  using  such  changes  to  update  your  cost  and  staff. 

6.  Let  us  say  that  at  some  point  in  the  project  the 
"Remaining  Effort"  is  1000  man  days,  the  "Remaining  Time"  is 
100  days  and  you  have  7  full  time  equivalent  employees 
working.  You  are,  thus,  in  a  position  where  you  have  to  use 
your  judgement  to  do  one  of  the  following: 

1.  Stick  with  the  current  schedule.  You  will  need  a 
staff  size  of  1000/100  =  10  full  time  employees. 

2.  Stick  with  your  staff  size  of  7.  This  means  the 
schedule  has  to  be  pushed  back.  In  this  case  the  model 
will  make  the  appropriate  adjustment  to  the  schedule  for 
you.  (For  example,  extend  it  to  1000/7  =  143  man  days) . 
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3.  Do  a  bit  of  both.  For  exaitple,  increase  the  staff 
size  to  8,  which  will  also  mean  that  the  schedule  will 
be  extended  appropriately  by  the  model  to  1000/8  =  125 
days . 


I 


1.  TRIAL  RUN 


(a)  Do  not  start  the  network.  From  the  C>  prompt, 
change  the  directory  to  IS4300. 

(b)  Type  TEST  to  begin  the  trial  run. 

(c)  The  system  will  show  you  some  introductory  screens 
and  instructions. 

(d)  The  simulation  will  run  through  the  first  simulation 
time  period  and  show  you  the  "MAIN  MENU" . 

(e)  DO  NOT  HIT  BNTBR  AFTER  MENU  SELECTIONS.  Press  1  tO 
view  the  status  report.  Please  be  sure  you  understand 
it  before  continuing. 

(f)  Press  <ENTER>  to  return  to  the  Main  Menu.  At  the 
Main  Menu,  press  2  to  prepare  for  another  simulation. 

(g)  The  screen  will  pron5)t  you  to  enter  an  estimate 
of  total  project  cost  and  staff  requirements  before 
performing  the  next  simulation.  Perform  steps  (d)  through 
(f)  for  as  many  intervals  as  necessary  (by  pressing  2  at  the 
Main  Menu) ,  until  you  are  comfortable  with  the  system.  Run 
the  project  for  a  minimum  of  2  intervals. 

(h)  After  you  are  finished  with  the  Trial  Run,  hit  <ESC> 
when  you  are  at  the  "MAIN  MENU"  screen  to  exit.  This  is 
the  only  time  you  should  hit  <ESC>. 

(i)  Remain  in  IS4300  directory.  Proceed  to  the 
experiment  (Para  2) . 

2.  EXPERIKBNT 

(a)  Type  EZPl  to  run  the  project. 

(b)  Follow  instructions  (c)  through  (f ) ;  ensure  you 
write  your  estimates  on  the  documentation  sheet  and 
enter  them  in  the  conputer  before  proceeding  with  each 
interval  simulation. 

(c)  Your  project  is  considered  conplete  when  "%  Reported 
Complete"»100  for  both  development  (e.g..  Design  and 
Coding)  and  testing. 


APPENDIX  H:  EXPERIMENT  DECISION  RECORD  SHEET 


Management's  Initial  Project  Estimates 

Initial  Estimate  of  Project  Size:  396  Tasks 
Initial  Estimate  of  Project  Cost:  1,111  Man  Days 
Initial  Estimate  of  Project  Duration:  320  Days 
Size  of  Initial  Core  Team:  5  People 

A  project  is  considered  complete  when  "%  Reported  Complete" 
=  100  for  both  development  work  (i.e.,  Design  and  Coding) 
and  testing. 

Please  enter  your  project  cost  estimates  and  staffing 
decisions  below: 


PROJECT  COST 


STAFFING ( PEOPLE ) 


Time 

elapsed 

- 

40  ( 

lays: 

Time 

elapsed 

- 

80  ( 

days : 

Time 

elapsed 

- 

120 

days : 

Time 

elapsed 

- 

160 

days: 

Time 

elapsed 

- 

200 

days : 

Time 

elapsed 

- 

240 

days: 

Time 

elapsed 

- 

280 

days: 

Time 

elapsed 

- 

320 

days: 

Time 

elapsed 

- 

360 

days : 

Time 

elapsed 

- 

400 

days: 

Time 

elapsed 

- 

440 

days: 

Time 

elapsed 

- 

480 

days: 

Time 

elapsed 

- 

520 

days: 

**• 

*** 
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APPENDIX  I:  SAMPLE  POPULATION  RANDOMIZING  WORKSHEET 


IS  4300 

SEGMENT  1 

A 

B 

C 

D 

E 

P  1 

BOWMAN 

90 

YOUNGBLOOD 

36 

LOCKHART 

m 

BROADWATER 

58 

ROSS 

52 

STEIN 

B  1 

BRYANT 

55 

MAIN 

06 

WRIGHT 

n 

CHELOUCHE 

89 

CULPEPPER 

44 

HALE 

B  J 

CHICHESTER 

53 

FEY 

65 

MAIN 

B 

CULPEPPER 

12 

HALE 

05 

CHICHESTER 

B  1 

FEY 

21 

KROTOW 

55 

IVEY 

B 

FOOTE 

60 

WRIGHT 

03 

WHITE 

B  1 

HALE 

25 

LOCKHART 

01 

SALTERS 

B 

IVEY 

84 

STEELE 

57 

MCDONALD 

KROTOW 

29 

PASADILLA 

82 

YOUNGBLOOD 

B 

LLANETA( ROGERS) 

95 

SALTERS 

24 

FOOTE 

B  1 

LOCKHART 

33 

WHITE 

23 

CULPEPPER 

B 

MAIN 

10 

SOONG 

95 

ROGERS 

B  1 

MCDONALD 

67 

CHICHESTER 

20 

1  ROSS  1 

D 

PASADILLA 

38 

BRYANT 

69 

KROTOW 

B  1 

ROSS 

08 

BROADWATER 

75 

STEELE 

B 

SALTERS 

42 

FOOTE 

37 

BOWMAN 

B  1 

SOONG 

49 

MCDONALD 

26 

FEY 

B 

STEIN 

80 

STEIN 

02 

BRYANT 

B  1 

WHITE 

43 

IVEY 

22 

CHELOUCHE 

B 

WRIGHT 

32 

CHELOUCHE 

75 

BROADWATER 

YOUNGBLOOD 

00 

BOWMAN 

65 

PASADILLA 

B 

STEELE 

34 

LLANETA (ROGERS) 

49 

SOONG 

B 

58 


IS  4300 


SBGNENT  2 
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APPENDIX  J:  SAS  DATA  AND  CONTROL  FILES  FOR  MANOVA 


FINAL  SCHEDULE  AND  COST 

OPTIONS  LINESIZE=80; 

DATA; 

INPUT  NAME  $  GROUP  $  SCHED  COST; 
INICOST=1111.00; 

INISCHED=320; 

DIFFSKED* (SCHED- INISCHED) /INISCHED; 
DIFFCOST= (COST-INICOST) /INICOST; 
COSTSKED= (DIFFCOST+DIFFSKED) /2 ; 
CARDS; 

BELL  A  297  1523.78 
BITTNER  A  302  1676.24 
BRANLEY  A  282  1909.99 
CHELOUCHE  A  372  1556.33 
CULPEPPER  A  317  1652.09 
FEY  A  283  1594.33 
FOSTERT  A  398  1531.88 
HODGKINS  A  292  1615.32 
IVEY  A  305  1532.61 
LACO  A  311  1480.42 
LOCKHART  A  364  1604.34 
MAIN  A  280  1884.17 
METCALF  A  402  1529.94 
PASADILLA  A  277  1604.49 
PENCE  A  347  1829.35 
POSEY  A  330  1516.01 
SABENE  A  417  1571.73 
SALTERS  A  240  1719.99 
STEELE  A  355  1783.24 
TOY  A  322  1680.84 
WRIGHT  A  380  1680.84 
YOUNG  A  269  1540.98 
BOWMAN  B  371  1579.01 
BOYD  B  274  1613.38 
BROADWATER  B  321  1686.92 
BRYANT  B  339  1595.71 
CHICHESTER  B  213  1657.98 
CLARK  B  253  1668 
DEFORD  B  361  1659.11 
FOOTE  B  245  1625.93 
FOSTERS  B  328  1553.51 
HALE  B  282  1590.12 
KROTOW  B  260  1691.94 
LANE  B  402  1552.16 
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MCDONALD  B  192  1894.69 
MONK  B  295  1643.82 
OWEN  B  262  1689.53 
POWERS  B  266  1529.39 
RANDALL  B  343  1617.03 
RHOADS  B  266  1976.98 
ROGERS  B  273  1605.92 
RUST  B  297  1769.05 
SHANNON  B  330  1676.37 
SMITH  B  312  1752.03 
SOONG  B  294  1622.87 
STEIN  B  208  1648.15 
WHITE  B  269  1656.34 

PROC  SORT;  BY  GROUP; 

PROC  MEANS; 

VAR  DIFFCOST  DIFFSKED  COSTSKED; 

BY  GROUP; 

TITLE  'STATISTICS  OF  GROUPS  A  AND  B' ; 

PROC  GLM; 

CLASS  GROUP; 

MODEL  DIFFCOST  DIFFSKED=GROUP; 

MANOVA  H=GROUP  /  PRINTS  PRINTH; 

TITLE  'MULTIVARIATE  ANOVA  OF  GROUPS  A  AND  : 
PROC  ANOVA; 

CLASSES  GROUP; 

MODEL  COSTSKED=GROUP; 

TITLE  'COST  +  SCHED  ANOVA  FOR  GROUPS  A  AND 


NOTEt  GROUP  GRADUAL  -  GROUP  A;  GROUP  ABRUPT  « 


; '  • 

’  / 

B'  ; 

GROUP  B 
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APPENDIX  K:  SAS  DATA  AND  CONTROL  FILES  FOR  REPEATED 
BCEASURES 


STAFF  DECISION  REPEATED  MEASURES 

OPTIONS  LINESIZE=80; DATA; INPUT  NAME  $  GROUP  $  T1  T2  T3  T4  T5 
T6; 

CARDS; 

BELL  A  5  5.3  5.5  5.5  5.6  6.2 

BITTNER  A  5  6  6  6  7  7 

BRANLEY  A  5.96  6.5  7.7  7.7  10.2  10.2 

CHELOUCHE  A  4  4  3  3  4 

CULPEPPER  A  5  5  7  7  7  4 

FEY  A5  5  4.8  5.6  8  5 

TFOSTER  A  5  5  5  5  5  3 

HODGKINS  A  5.5  5.5  6  6.5  6.5  6.8 

IVEY  A  6  6  6  6  5  4 

LACO  A  5.5  5.5  4.9  4.9  4.8  4.8 

LOCKHART  A  4.5  4  3.5  3.5  5.5  6 

MAIN  A  7  7  7.5  8.5  8.5  8.5 

METCALF  A6  6  5.5  2.6  2  2 

PASADILLA  A  5  6  6  7  8  8 

PENCE  A  6  6  6  5  5  5 

POSEY  A  6  6  6  5  4  4 

SABENE  A  5  5  1  1  1  5 

SALTERS  A  5.5  10.5  10.5  10.5  6  5 

STEELE  A  6  6  6  4.5  4.5  4.5 

TOY  A55. 55556 

WRIGHT  A  5  5  6  5  5  6 

YOUNG  A6  6  6.5  6.5  7  7 

BOWMAN  B  5  4  6  3  3  5 

BOYD  B  5  6  7  8  8  6 

BROADWATER  B  5  5  6  6  6  6 

BRYANT  B4. 546665 

CHICHESTER  B  9  10  10  10  10  . 

CLARK  B  5.5  7  10  8  8.5  8.5 
DEFORD  B  5  4  4  5  5  5 
FOOTE  B  6  7  8  9  10  10 
SFOSTER  B  5  5  5  5  5  5 
HALE  B  5.5  5.5  6.5  6.5  7  7 
KROTOW  B  6  6  11  8  8  8 
LANE  B  6  5  5  4  2  2 
MCDONALD  B  7  12  20  20  .  . 

MONK  B  5  5  7.5  7.5  7.5  5 
OWEN  B  5  6  9  9  9  7 
POWERS  555. 33. 534 
RANDALL  B  5  5  5  5  5  6 
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RHOADS  B  6.5  6.5  12.1  12.1  8  9 

ROGERS  B  6  6  7  7  7  7 

RUST  B  6  6  7  7  7  7 

SHANNON  B55665.55 

SMITH  B  3.5  3.5  3.5  8.9  8.9  8.9 

SOONG  B  5  5  6  6  7  8 

STEIN  B  10  10  10  10  10 

WHITE  B  7  7  7  7  7  7 

PROC  SORT;  BY  GROUP; 

PROC  GLM; 

CLASS  GROUP; 

MODEL  T1 -T6=GROUP /NOUNI; 

REPEATED  TIME  /  SHORT  SUMMARY; 

TITLE  'STAFFING  LEVEL  DECISIONTS' ; 

TITLE3  'REPEATED  MEASURES  FOR  GROUP  A  VERSUS  GROUP  B' ; 


NOTE:  GROUP  GRADUAL  «  GROUP  A,  GROUP  ABRUPT  c  GROUP  B 
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APPENDIX  L:  SAS  DATA  AND  CONTROL  FILES  FOR  REPEATED 
MEAST7RES 


PROJECT  COST  ESTIMATE  DECISION  REPEATED  MEASURES 

OPTIONS  LINESIZE=80; DATA; INPUT  NAME  $  GROUP  $  T1  T2  T3  T4  T5 
T6; 

CARDS; 

BELL  A 

BITTNER  A  5  6  6  6  7  7 

BRANLEY  A  5.96  6.5  7.7  7.7  10.2  10.2 

CHELOUCHE  A  4  4  3  3  4 

CULPEPPER  A  5  5  7  7  7  4 

FEY  A5  5  4.8  5.6  8  5 

TFOSTER  A  5  5  5  5  5  3 

HODGKINS  A  5.5  5.5  6  6.5  6.5  6.8 

IVEY  A  6  6  6  6  5  4 

LACO  A  5.5  5.5  4.9  4.9  4.8  4.8 

LOCKHART  A  4.5  4  3.5  3.5  5.5  6 

MAIN  A  7  7  7.5  8.5  8.5  8.5 

METCALF  A6  6  5.5  2.6  2  2 

PASADILLA  A  5  6  6  7  8  8 

PENCE  A  6  6  6  5  5  5 

POSEY  A  6  6  6  5  4  4 

SABENE  A  5  5  1  1  1  5 

SALTERS  A  5.5  10.5  10.5  10.5  6  5 

STEELE  A  6  6  6  4.5  4.5  4.5 

TOY  A55. 55556 

WRIGHT  A  5  5  6  5  5  6 

YOUNG  A6  6  6.5  6.5  7  7 

BOWMAN  B  5  4  6  3  3  5 

BOYD  B  5  6  7  fl  8  6 

BROADWATER  B  5  5  6  6  6  6 

BRYANT  B4. 546665 

CHICHESTER  B  9  10  10  10  10  . 

CLARK  B  5.5  7  10  8  8.5  8.5 
DEFORD  B  5  4  4  5  5  5 
FOOTE  B  6  7  8  9  10  10 
SFOSTER  B  5  5  5  5  5  5 
HALE  B  5.5  5.5  6.5  6.5  7  7 
KROTOW  B  6  6  11  8  8  8 
LANE  B  6  5  5  4  2  2 
MCDONALD  B  7  12  20  20  .  . 

MONK  B  5  5  7.5  7.5  7.5  5 
OWEN  B  5  6  9  9  9  7 
POWERS  555. 33. 534 
RANDALL  B  5  5  5  5  5  6 
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RHOADS  B  6.5  6.5  12.1  12.1  8  9 

ROGERS  B  6  6  7  7  7  7 

RUST  B  e  6  1  1  1  1 

SHANNON  B55665.55 

SMITH  B  3.5  3.5  3.5  8.9  8.9  8.9 

SOONG  B  5  5  6  6  7  8 

STEIN  B  10  10  10  10  10 

WHITE  B  7  7  7  7  7  7 

PROC  SORT;  BY  GROUP; 

PROC  GLM; 

CLASS  GROUP; 

MODEL  T1 - T6  =GROUP/NOUNI ; 

REPEATED  TIME  /  SHORT  SUMMARY; 

TITLE  'STAFFING  LEVEL  DECISIONTS' ; 

TITLE3  'REPEATED  MEASURES  FOR  GROUP  A  VERSUS  GROUP  B' ; 

NOTE:  GROUP  GRADUAL  -  GROUP  A;  GROUP  ABRUPT  -  GROUP  B 
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